AI Agent Orchestrator는 실제 서비스 아키텍처와 미들웨어까지 포함한 구조이다.

AI Agent 구조를 설명할 때 우리는 보통 이런 다이어그램을 봅니다.

User
 ↓
Orchestrator
 ↓
LLM
 ↓
Tools

이 구조는 개념적으로는 맞습니다.

하지만 실제 서비스를 만들기 시작하면 곧 이런 질문이 생깁니다.

“그래서 Orchestrator는 실제로 어떤 시스템인가?”

단순한 함수일까요?
아니면 별도의 서버일까요? 혹은 어떤 프레임워크가 있을까요?

정답은 하나가 아닙니다. 하지만 실제 서비스에서는 Orchestrator가 하나의 작은 플랫폼처럼 구성되는 경우가 많습니다.

실제 Production 구조

현실적인 Agent 시스템 구조는 보통 이렇게 생깁니다.

User
 ↓
API Gateway
 ↓
Agent Service (Orchestrator)
 ↓
--------------------------------
|  LLM Router                   |
|  Tool Registry                |
|  State Manager                |
|  Task Queue                   |
|  Event Stream                 |
--------------------------------
 ↓
Tools / Virtual Computer / APIs

여기서 Agent Service가 바로 Orchestrator입니다.

하지만 그 안에는 여러 컴포넌트가 들어갑니다.

Orchestrator 내부 구조

Orchestrator를 실제 코드 레벨로 보면 대략 이런 구조가 됩니다.

Orchestrator

├─ LLM Router
├─ Tool Registry
├─ Workflow Engine
├─ State Manager
├─ Task Queue
└─ Event Stream

각 역할을 보면 생각보다 명확합니다.

1. LLM Router: Agent는 하나의 LLM만 쓰지 않는 경우가 많습니다.

예를 들어

GPT
Claude
Local Llama

여러 모델이 있을 수 있습니다. 그래서 Orchestrator는 이런 역할을 합니다.

task type
 ↓
model selection
 ↓
LLM call

예

요약 → local LLM
복잡한 reasoning → GPT

이걸 LLM Router라고 부르는 경우가 많습니다.

2. Tool Registry : Agent가 사용할 수 있는 Tool 목록을 관리합니다.

예를 들어

web_search
browser
code_executor
file_system
database_query

LLM이 tool call을 반환하면

tool name
 ↓
registry lookup
 ↓
tool execution

을 수행합니다. 보통 이런 구조입니다.

tools = {
 "web_search": web_search_tool,
 "browser": browser_tool,
 "python": code_executor
}

3. Workflow Engine : 이게 사실 Orchestrator의 핵심입니다.

Agent는 보통 loop 기반 workflow로 동작합니다.

LLM
 ↓
Tool call
 ↓
Execute
 ↓
Result
 ↓
LLM

이걸 계속 반복합니다.

그래서 실제 코드에서는 이런 루프가 존재합니다.

while not finished:

    response = llm(messages)

    if response.tool:
        result = run_tool(response.tool)

        messages.append(result)

    else:
        finished = True

이 루프를 관리하는 것이 Workflow Engine입니다.

4. State Manager : Agent는 작업 중간 상태를 계속 저장해야 합니다.

예를 들어

research results
intermediate summaries
draft

같은 데이터입니다 그래서 Orchestrator는 보통 상태를 저장합니다.

예

Redis
PostgreSQL
Vector DB

특히 long task Agent에서는 이 상태 관리가 매우 중요합니다.

5. Task Queue : 실제 서비스에서는 Agent 작업이 오래 걸립니다.

예를 들어

리서치 작업
보고서 생성
데이터 분석

몇 분이 걸릴 수도 있습니다. 그래서 대부분 이런 구조를 사용합니다.

API
 ↓
Task Queue
 ↓
Worker

대표적인 미들웨어는

Redis Queue
Celery
RabbitMQ
Kafka

같은 것들입니다.

즉 Orchestrator는 Worker 시스템 위에서 동작하는 경우가 많습니다.

6. Event Stream : Agent 시스템에서는 UI에 진행 상황을 보여주는 것이 중요합니다.

예를 들어 ChatGPT UI를 보면

검색 중
코드 실행 중
요약 생성 중

같은 메시지가 나옵니다.

이것은 사실 Orchestrator 이벤트입니다.

예

tool_started
tool_completed
agent_step

이 이벤트는 보통

WebSocket
SSE
Kafka

같은 스트림으로 전달됩니다. 그래서 구조는 이렇게 됩니다.

Orchestrator
 ↓
Event Bus
 ↓
Frontend

그래서 Orchestrator는 결국 무엇일까

이제 정리해보겠습니다. Orchestrator는 단순한 함수가 아닙니다.

실제 서비스에서는 보통 이런 시스템입니다.

Agent Orchestrator

ㄴ LLM Router
ㄴ Tool System
ㄴ Workflow Engine
ㄴ State Manager
ㄴ Task Queue
ㄴ Event Stream

즉 사실상 Agent runtime platform입니다.

그래서 많은 Agent 프레임워크들이 이 문제를 해결하려고 합니다.

예를 들면

LangGraph
AutoGen
CrewAI

같은 것들입니다.

하지만 실제 서비스를 만들다 보면 대부분 팀은 결국 자체 Orchestrator를 만들게 됩니다.

왜냐하면

tool 구조
workflow
UI
state

가 서비스마다 전부 다르기 때문입니다.